home *** CD-ROM | disk | FTP | other *** search
/ PC World Interactive 7 / PC World Interactive 7.iso / program / dosref.EXE / CHAPTER.007 < prev    next >
Text File  |  1996-01-31  |  47KB  |  850 lines

  1.  
  2.    **  Programmer's Technical Reference for MSDOS and the IBM PC **
  3.  
  4.                       C H A P T E R    S E V E N
  5.  
  6.                           DOS FILE STRUCTURE
  7.  
  8.                             C O N T E N T S
  9.  
  10. File Management Functions ....................................... 7**1
  11. FCB Function Calls .............................................. 7**2
  12. Handle Function Calls ........................................... 7**3
  13. Special File Handles ............................................ 7**4
  14. Raw and Cooked File I/O ......................................... 7**5
  15. Number of Open Files Allowed  ................................... 7**6
  16. Restrictions on FCB Usage ....................................... 7**7
  17. Restrictions on Handle usage .................................... 7**8
  18. Allocating Space to a File ...................................... 7**9
  19. MSDOS / PCDOS Differences ....................................... 7**10
  20. .COM File Structure ............................................. 7**11
  21. .EXE File Structure ............................................. 7**12
  22. The Relocation Table ............................................ 7**13
  23. "NEW" .EXE Format (Microsoft Windows and OS/2) .................. 7**14
  24. Standard File Control Block ..................................... 7**15
  25. Extended File Control Block ..................................... 7**16
  26. Disk Transfer Area .............................................. 7**17
  27.  
  28.  
  29.  
  30. File Management Functions ....................................... 7**1
  31.  
  32.   Use DOS function calls to create, open, close, read, write, rename, 
  33. find, and erase files.  There are two sets of function calls that DOS 
  34. provides for support of file management. They are: 
  35.  
  36.    * File Control Block function calls   (0Fh-24h)
  37.    * Handle function calls               (39h-69h)
  38.  
  39.   Handle function calls are easier to use and are more powerful than 
  40. FCB calls. Microsoft recommends that the handle function calls be used 
  41. when writing new programs.  DOS 3.0 up have been curtailing use of FCB 
  42. function calls; it is possible that future versions of DOS may not 
  43. support FCB function calls. 
  44.  
  45.   The following table compares the use of FCB calls to Handle function 
  46. calls: 
  47.  
  48. ┌─────────────────────────────┬─────────────────────────────────────────┐
  49. │           FCB Calls         │               Handle Calls              │
  50. ├─────────────────────────────┼─────────────────────────────────────────┤
  51. │  Access files in current    │  Access files in ANY directory          │
  52. │  directory only.            │                                         │
  53. │                             │                                         │
  54. │  Requires the application   │  Does not require use of an FCB.        │
  55. │  program to maintain a file │  Requires a string with the drive,      │
  56. │  control block to open,     │  path, and filename to open, create,    │
  57. │  create, rename or delete   │  rename, or delete a file. For file     │
  58. │  a file. For I/O requests,  │  I/O requests, the application program  │
  59. │  the application program    │  must maintain a 16 bit file handle     │
  60. │  also needs an FCB          │  that is supplied by DOS.               │
  61. └─────────────────────────────┴─────────────────────────────────────────┘
  62.  
  63.   The only reason an application should use FCB function calls is to 
  64. maintain the ability to run under DOS 1.x.  To to this, the program 
  65. may use only function calls 00h-2Eh.  Though the FCB function calls 
  66. are frowned upon, many of the introductory assembly language 
  67. programming texts use the FCB calls as examples. 
  68.  
  69.   PC-MOS/386 supports the FCB calls but recommends using the handle 
  70. calls. 
  71.  
  72.  
  73.  
  74. FCB Function Calls .............................................. 7**2
  75.  
  76.   FCB function calls require the use of one File Control Block per 
  77. open file, which is maintained by the application program and DOS.  
  78. The application program supplies a pointer to the FCB and fills in the 
  79. appropriate fields required by the specific function call.  An FCB 
  80. function call can perform file management on any valid drive, but only 
  81. in the current logged directory.  By using the current block, current 
  82. record, and record length fields of the FCB, you can perform 
  83. sequential I/O by using the sequential read or write function calls.  
  84. Random I/O can be performed by filling in the random record and record 
  85. length fields. 
  86.  
  87.   Several possible uses of FCB type calls are considered programming 
  88. errors and should not be done under any circumstances to avoid 
  89. problems with file sharing and compatibility with later versions of 
  90. DOS. 
  91.  
  92.  Some errors are:
  93.  
  94. 1) If program uses the same FCB structure to access more than one open 
  95.    file. By opening a file using an FCB, doing I/O, and then replacing 
  96.    the filename field in the file control block with a new filename, a 
  97.    program can open a second file using the same FCB. This is invalid 
  98.    because DOS writes control information about the file into the 
  99.    reserved fields of the FCB. If the program replaces the filename 
  100.    field with the original filename and then tries to perform I/O on 
  101.    this file, DOS may become confused because the control information 
  102.    has been changed. An FCB should never be used to open a second file 
  103.    without closing the one that is currently open. If more than one 
  104.    File Control Block is to be open concurrently, separate FCBs should 
  105.    be used. 
  106.  
  107. 2) A program should never try to use the reserved fields in the FCB, 
  108.    as the function of the fields may change with different versions of 
  109.    DOS. 
  110.  
  111. 3) A delete or a rename on a file that is currently open is considered 
  112.    an error and should not be attempted by an application program. 
  113.  
  114.   It is also good programming practice to close all files when I/O is 
  115. done. This avoids potential file sharing problems that require a limit 
  116. on the number of files concurrently open using FCB function calls. 
  117.  
  118.  
  119.  
  120. Handle Function Calls ........................................... 7**3
  121.  
  122.   The recommended method of file management is by using the extended 
  123. "handle" set of function calls.  These calls are not restricted to the 
  124. current directory.  Also, the handle calls allow the application 
  125. program to define the type of access that other processes can have 
  126. concurrently with the same file if the file is being shared. 
  127.  
  128.   To create or open a file, the application supplies a pointer to an 
  129. ASCIIZ string giving the name and location of the file.  The ASCIIZ 
  130. string contains an optional drive letter, optional path, mandatory 
  131. file specification, and a terminal byte of 00h.  The following is an 
  132. example of an ASCIIZ string: 
  133.  
  134.      format:          [drive][path] FILENAME.EXT,0
  135.  
  136.      in MASM:         db "A:\PATH\FILENAME.EXT",0
  137.  
  138.   If the file is being created, the application program also supplies 
  139. the attribute of the file.  This is a set of values that defines the 
  140. file read-only, hidden, system, directory, or volume label. 
  141.  
  142.   If the file is being opened, the program can define the sharing and 
  143. access modes that the file is opened in.  The access mode informs DOS 
  144. what operations your program will perform on this file (read-only, 
  145. write-only, or read/write).  The sharing mode controls the type of 
  146. operations other processes may perform concurrently on the file.  A 
  147. program can also control if a child process inherits the open files of 
  148. the parent.  The sharing mode has meaning only if file sharing is 
  149. loaded when the file is opened. 
  150.  
  151.   To rename or delete a file, the appplication program simply needs to 
  152. provide a pointer to the ASCIIZ string containing the name and 
  153. location of the file and another string with the new name if the file 
  154. is being renamed. 
  155.  
  156.   The open or create function calls return a 16-bit value referred to 
  157. as the file handle.  To do any I/O to a file, the program uses the 
  158. handle to reference the file.  Once a file is opened, a program no 
  159. longer needs to maintain the ASCIIZ string pointing to the file, nor 
  160. is there any need to stay in the same directory.  DOS keeps track of 
  161. the location of the file regardless of what directory is current. 
  162.  
  163.   Sequential I/O can be performed using the handle read (3Fh) or write 
  164. (40h) function calls.  The offset in the file that I/O is performed to 
  165. is automatically moved to the end of what was just read or written.  
  166. If random I/O is desired, the LSEEK (42h) function call can be used to 
  167. set the offset into the file where I/O is to be performed. 
  168.  
  169.  
  170.  
  171. Special File Handles ............................................ 7**4
  172.  
  173.   DOS reserves five special file handles for use by itself and 
  174. applications programs. They are: 
  175.  
  176. ┌───────┬────────┬──────────────────────────────────────────────────────┐
  177. │ 0000h │ STDIN  │ standard input device   (input can be redirected)    │
  178. │ 0001h │ STDOUT │ standard output device  (output can be redirected)   │
  179. │ 0002h │ STDERR │ standard error output device (output cannot be       │
  180. │       │        │                               redirected)            │
  181. │       │        │ NOTE: DOS opens STDERR for both writing and reading. │
  182. │       │        │  Since STDIN can be redirected, using STDERR to read │
  183. │       │        │  the keyboard is a reliable way to ensure that your  │
  184. │       │        │  program is actually                                 │
  185. │       │        │ reading the keyboard, if that's what you want to do. │
  186. │ 0004h │ STDAUX │ standard auxiliary device                            │
  187. │ 0005h │ STDPRN │ standard printer device (PRN, normally LPT1)         │
  188. └───────┴────────┴──────────────────────────────────────────────────────┘
  189.  
  190.   These handles are predefined by DOS and can be used by an 
  191. application program.  They do not need to be opened by a program, 
  192. although a program can close these handles.  STDIN should be treated 
  193. as a read-only file, and STDOUT and STDERR should be treated as write-
  194. only files.  STDIN and STDOUT can be redirected.  All handles 
  195. inherited by a process can be redirected, but not at the command line. 
  196.  
  197.   These handles are very useful for doing I/O to and from the console 
  198. device.  For example, you could read input from the keyboard using the 
  199. read (3Fh) function call and file handle 0000h (STDIN), and write 
  200. output to the console screen with the write function call (40h) and 
  201. file handle 0001h (STDOUT).  If you wanted an output that could not be 
  202. redirected, you could output it using file handle 0002h (STDERR).  
  203. This is very useful for error messages that must be seen by a user. 
  204.  
  205.   File handles 0003h (STDAUX) and 0004h (STDPRN) can be both read from 
  206. and written to.  STDAUX is typically a serial device and STDPRN is 
  207. usually a parallel device. 
  208.  
  209.   DOS 2.0 through 3.21 were limited to 20 file handles.  This limited 
  210. application programs to 15 simultaneous handles.  DOS 3.3 and higher 
  211. added the int 21h/ Set Handle Count function to give up to 65,535 file 
  212. handles per application.  PC-MOS/386 can have more than 65,535 
  213. handles. 
  214.  
  215.  
  216. Raw and Cooked File I/O ......................................... 7**5
  217.  
  218.   Raw and cooked modes originated in the Unix world and were provided 
  219. with DOS 2.x+.  They apply only to character I/O (including the 
  220. keyboard, screen, printer and serial ports - but not block devices 
  221. like disk drives), and only to the "new" 2.x file handle I/O functions 
  222. (not the old FCB file I/O functions).  Raw mode is called "binary" 
  223. mode in DOS 3.x+, and cooked mode is called "ASCII."  The common raw-
  224. cooked convention is from DOS 2.x and other operating systems. 
  225.  
  226.   The five predefined DOS file handles are all devices, so the mode 
  227. can be changed from raw to cooked via IOCTL.  These handles are in 
  228. cooked mode when initialized by DOS.  Regular file handles that are 
  229. not devices are always in raw mode and cannot be changed to cooked 
  230. mode. 
  231.  
  232.   The predefined file handles STDIN (0000h) and STDOUT (0001h) and 
  233. STDERR (0002h) are all duplicate handles.  If the IOCTL function call 
  234. is used to change the mode of any of these three handles, the mode of 
  235. all three handles is changed.  For example, if IOCTL was used to 
  236. change STDOUT to raw, then STDIN and STDERR would also be changed to 
  237. raw mode. 
  238.  
  239.   In the default cooked mode, DOS examines the character I/O data 
  240. stream for certain special control characters, and takes specific 
  241. actions if they are found.  For example, Ctrl-C is treated as a Break 
  242. interrupt, Ctrl-S pauses the screen display, and Ctrl-Z is treated as 
  243. end-of-file. (If you try to send Ctrl-Z to a printer through a DOS 
  244. file handle in cooked mode, DOS closes the printer file!)  Also, input 
  245. is buffered within DOS until a CR is detected - so you can't process 
  246. each key as it is pressed. 
  247.  
  248.   In raw mode, DOS ignores special characters, passing them through 
  249. without any special processing, and does not buffer input lines.  So 
  250. to use file handle I/O to send bit-mapped graphics to a printer 
  251. through DOS, or process individual keystrokes immediately, or bypass 
  252. Ctrl-C checking, you need to switch the file handle to raw mode.  Raw 
  253. mode is not automatically reset to cooked mode by DOS when a program 
  254. terminates, so it is a good idea to reset the file into cooked mode 
  255. before your program exits if the system was in cooked mode to begin 
  256. with. I/O to files is done in raw mode. 
  257.  
  258.   To set a file handle into raw mode or back into cooked mode, use DOS 
  259. IOCTL (int 21h Fn 44h, Chapter 4): 
  260.  
  261.    1.  Get the current mode bits (Subfunction 0).
  262.    2.  Check that the file is a character file.  (If not, exit.)
  263.    3.  Switch the cooked mode bit to raw or vice versa.
  264.    4.  Set the mode bits (Subfunction 1).
  265.  
  266.   Microsoft C v4 and later do NOT set raw mode for binary files.  When 
  267. running with the CON driver set to raw mode (to enhance display speed) 
  268. programs compiled in MSC will crash the computer.  A letter to 
  269. Microsoft reporting this odd behavior got the somewhat bizarre reply 
  270. that "Microsoft does not support the use of any TSRs" from their 
  271. techs.  Raw mode is clearly documented by both IBM and Microsoft, and 
  272. their own tools should take it into account. 
  273.  
  274.  
  275.  
  276. FILE I/O IN BINARY (RAW) MODE
  277.  
  278. The following is true when a file is read in binary mode:
  279.  
  280. 1)  The characters ^S (scroll lock), ^P (print screen), ^C (control
  281.     break) are not checked for during the read.  Therefore, no printer
  282.     echo occurs if ^S or ^P are read.
  283. 2)  There is no echo to STDOUT (0001h).
  284. 3)  Read the number of specified bytes and returns immediately when the
  285.     last byte is received or the end of file reached.
  286. 4)  Allows no editing of the input using the function keys if the input
  287.     is from STDIN (0000h).
  288.  
  289.  
  290. The following is true when a file is written to in binary mode:
  291.  
  292. 1)  The characters ^S (scroll lock), ^P (print screen), ^C (control
  293.     break) are not checked for during the write.  Therefore, no printer
  294.     echo occurs.
  295. 2)  There is no echo to STDOUT (0001h).
  296. 3)  The exact number of bytes specified are written.
  297. 4)  Does not caret (^) control characters. For example, Ctrl-D is sent
  298.     out as byte 04h instead of the two bytes ^ and D.
  299. 5)  Does not expand tabs into spaces.
  300.  
  301.  
  302. FILE I/O IN ASCII (COOKED) MODE
  303.  
  304. The following is true when a file is read in ASCII mode:
  305.  
  306. 1)  Checks for the characters ^C,^S, and ^P.
  307. 2)  Returns as many characters as there are in the device input buffer,
  308.     or the number of characters requested, whichever is less.  If the
  309.     number of characters requested was less than the number of
  310.     characters in the device buffer, then the next read will address
  311.     the remaining characters in the buffer.
  312. 3)  If there are no more bytes remaining in the device input buffer,
  313.     read a line (terminated by a CR) into the buffer.  This line may
  314.     be edited with the function keys.  The characters return terminated
  315.     with a sequence of 0Dh, 0Ah (CR, LF) if the number of characters
  316.     requested is sufficient to include them.  For example, if 5
  317.     characters were requested, and only 3 were entered before the
  318.     carriage return (0Dh or ^M) was presented to DOS from the console
  319.     device, then the 3 characters entered and 0Dh and 0Ah would be
  320.     returned.  However, if 5 characters were requested and 7 were
  321.     entered before the carriage return, only the first 5 characters
  322.     would be returned.  No 0Dh, 0Ah sequence would be returned in this
  323.     case.  If less than the number of characters requested are entered
  324.     when the carriage return is received, the characters received and
  325.     0Dh, 0Ah would be returned.  The reason the 0Ah (linefeed or ^J)
  326.     is added to the returned characters is to make the devices look
  327.     like text files.
  328. 4)  If a 1Ah (^Z) is found, the input is terminated at that point.
  329.     No 0Dh, 0Ah (CR,LF) sequence is added to the string.
  330. 5)  Echoing is performed.
  331. 6)  Tabs are expanded.
  332.  
  333.  
  334. The following is true when a file is written to in ASCII mode:
  335.  
  336. 1)  The characters ^S,^P,and ^C are checked for during the write
  337.     operation.
  338. 2)  Expands tabs to 8-character boundaries and fills with spaces
  339.     (20h).
  340. 3)  Carets indicate control chars, for example, ^D is written as
  341.     two bytes, '^' and 'D'.
  342. 4)  Bytes are output until the number specified is output or a ^Z is
  343.     encountered.  The number actually output is returned to the user.
  344.  
  345.  
  346.  
  347. Number of Open Files Allowed  ................................... 7**6
  348.  
  349.   The number of files that can be open concurrently is restricted by 
  350. DOS.  This number is determined by how the file is opened or created 
  351. (FCB or handle function call) and the number specified by the FCBS and 
  352. FILES commands in the CONFIG.SYS file.  The number of files allowed 
  353. open by FCB function calls and the number of files that can be opened 
  354. by handle type calls are independent of one another. 
  355.  
  356.  
  357.  
  358. Restrictions on FCB Usage ....................................... 7**7
  359.  
  360.   If file sharing is not loaded using the SHARE command, there is no 
  361. restriction on the number of files concurrently open using FCB 
  362. function calls. 
  363.  
  364.   However, when file sharing is loaded, the maximum number of FCBs 
  365. open is set by the the FCBS command in the CONFIG.SYS file. 
  366.  
  367.   The FCBS command has two values you can specify, 'm' and 'n'.  The 
  368. value for 'm' specifies the number of files that can be opened by 
  369. FCBs, and the value 'n' specifies the number of FCBs that are 
  370. protected from being closed. 
  371.  
  372.   When the maximum number of FCB opens is exceeded, DOS automatically 
  373. closes the least recently used file.  Any attempt to access this file 
  374. results in an int 24h critical error message "FCB not available".  If 
  375. this occurs while an application program is running, the value 
  376. specified for 'm' in the FCBS command should be increased. 
  377.  
  378.   When DOS determines the least recently used file to close, it does 
  379. not include the first 'n' files opened, therefore the first 'n' files 
  380. are protected from being closed. 
  381.  
  382.  
  383.  
  384. Restrictions on Handle usage .................................... 7**8
  385.  
  386.   The number of files that can be open simultaneously by all processes 
  387. is determined by the FILES command in the CONFIG.SYS file.  The number 
  388. of files a single process can open depends on the value specified for 
  389. the FILES command.  If FILES is greater than or equal to 20, a single 
  390. process can open 20 files.  If FILES is less than 20, the process can 
  391. open less than 20 files. This value includes the three predefined 
  392. handles STDIN, STDOUT, and STDERR.  This means only 17 additional 
  393. handles can be added. DOS 3.3+ includes a function to use more than 20 
  394. files per application. 
  395.  
  396.  
  397.  
  398. Allocating Space to a File ...................................... 7**9
  399.  
  400.   Files are not necessarily written sequentially on a disk.  Space is 
  401. allocated as needed and the next location available on the disk is 
  402. allocated as space for the next file being written.  Therefore, if 
  403. considerable file generation has taken place, newly created files will 
  404. not be written in sequential sectors. However, due to the mapping 
  405. (chaining) of file space via the File Allocation Table (FAT) and the 
  406. function calls available, any file may be used in either a sequential 
  407. or random manner. 
  408.  
  409.   Space is allocated in increments called clusters.  Cluster size 
  410. varies according to the media type.  An application program should not 
  411. concern itself with the way that DOS allocates space to a file.  The 
  412. size of a cluster is only important in that it determines the smallest 
  413. amount of space that can be allocated to a file.  A disk is considered 
  414. full when all clusters have been allocated to files. 
  415.  
  416.   A DOS file can be up to (2^32)-1 (4,294,967,295) bytes long.  This 
  417. is the maximum value that can be put in the dword in the FAT which 
  418. holds the file size information, less one byte for the end of file 
  419. marker. 
  420.  
  421.  
  422.  
  423. MSDOS / PCDOS Differences ....................................... 7**10
  424.                                                 
  425.   There is a problem of compatibility between MS-DOS and IBM PC-DOS 
  426. having to do with FCB Open and Create.  The IBM 1.0, 1.1, and 2.0 
  427. documentation of OPEN (call 0Fh) contains the following statement: 
  428.  
  429.   "The current block field (FCB bytes C-D) is set to zero [when an FCB 
  430. is opened]." 
  431.  
  432.   This statement is NOT true of MS-DOS 1.25 or MS-DOS 2.00.  The 
  433. difference is intentional, and the reason is CP/M 1.4 compatibility.  
  434. Zeroing that field is not CP/M compatible.  Some CP/M programs will 
  435. not run when machine translated if that field is zeroed.  The reason 
  436. it is zeroed in the IBM versions is that IBM specifically requested 
  437. that it be zeroed.  This was the reason for the complaints from some 
  438. vendors about the fact that IBM MultiPlan would not run under MS-DOS. 
  439. It is probably the reason that some other very old IBM programs didn't
  440. run under MS-DOS. 
  441.  
  442. NOTE: Do what all MS/PC-DOS systems programs do: Set every single FCB 
  443. field you want to use regardless of what the documentation says is 
  444. initialized. 
  445.  
  446.  
  447.  
  448. .COM File Structure ............................................. 7**11
  449.  
  450.   The COM file structure was designed for DOS 1.0 and maximum 
  451. compatibility with programs ported from the CP/M operating system.  
  452. COM files normally comprise one segment only.  A COM file is loaded as 
  453. a memory image of the disk file and the Instruction Pointer is set to 
  454. offset 100h within the program. 
  455.  
  456.   The BIN files generated by EXE2BIN are COM files.
  457.  
  458.  
  459.  
  460. .EXE File Structure ............................................. 7**12
  461.  
  462.   The EXE file is the native mode for DOS.  EXE files may make use of 
  463. multiple segments for code, stack, and data.  The design of the EXE 
  464. file reflects the segmented design of the Intel 80x86 CPU 
  465. architecture.  EXE files may be as large as available memory and may 
  466. make references to specific segment addresses. 
  467.  
  468.   The EXE files produced by the Microsoft linker program consist of 
  469. two parts, control and relocation information and the load module 
  470. itself. 
  471.  
  472.   The control and relocation information, which is described below, is 
  473. at the beginning of the file in an area known as the header.  The load 
  474. module immediately follows the header.  The load module begins in the 
  475. memory image of the module contructed by the Microsoft linker. 
  476.  
  477.   When you are loading a file with the name *.EXE, DOS does NOT assume 
  478. that it is an EXE format file.  It looks at the first two bytes for a 
  479. signature (the letters MZ) telling it that it is an EXE file.  If it 
  480. has the proper signature, then the load proceeds.  Otherwise, it 
  481. presumes the file to be a .COM format file. 
  482.  
  483.   If the file has the EXE signature, then the internal consistency is 
  484. checked.  Pre-2.0 versions of MSDOS did not check the signature byte 
  485. for EXE files. 
  486.  
  487.   The .EXE format can support programs larger than 64K.  It does this 
  488. by allowing separate segments to be defined for code, data, and the 
  489. stack, each of which can be up to 64K long.  Programs in EXE format 
  490. may contain explicit references to segment addresses.  A header in the 
  491. EXE file has information for DOS to resolve these references. 
  492.  
  493.   EXE file size does not reflect the amount of RAM an EXE file might 
  494. use, since stack space or extra RAM may be allocated by the EXE loader 
  495. at init.  Some programs may also store their overlay files in the main 
  496. EXE file. 
  497.  
  498.   EXE files produced by the Microsoft linker are considered to be 
  499. standard EXEs.  Digital Research's RASM86 linker produces quite 
  500. different EXE files, as do the linkers from SLR Systems and Phoenix.  
  501. Intel's original linker for their 8086 compiler is much more 
  502. sophisticated than the Microsoft linker, which originally was a simple 
  503. subset of the Intel linker.  Unfortunately the new fields added by 
  504. OS/2, Windows, and CodeView make the newer Microsoft linkers somewhat 
  505. different from the original Intel linker. 
  506.  
  507.  
  508. ┌───────────────────────────────────────────────────────────────────────┐
  509. │                     E X E   F I L E   H E A D E R                     │
  510. ├─────────┬──────┬──────────────────────────────────────────────────────┤
  511. │ Offset  │ Size │                 C O N T E N T S                      │
  512. ├─────────┼──────┼─────┬────────────────────────────────────────────────┤
  513. │   00h   │ BYTE │ 4Dh │ The Linker's signature to mark the file as a   │
  514. ├─────────┼──────┼─────┤ valid .EXE file (ASCII letters M and Z, for    │
  515. │   01h   │ BYTE │ 5Ah │ Mark Zbikowski, one of the major DOS           │
  516. │         │      │     │ programmers at Microsoft)                      │
  517. ├─────────┼──────┼─────┴────────────────────────────────────────────────┤
  518. │ 02h-03h │ WORD │ Length of the image mod 512 (remainder after dividing│
  519. │         │      │ the load module image size by 512) (including header)│
  520. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  521. │ 04h-05h │ WORD │ Size of the file in 512 byte pages including the     │
  522. │         │      │ header.                                              │
  523. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  524. │ 06h-07h │ WORD │ Number of relocation table items following the header│
  525. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  526. │ 08h-09h │ WORD │ Size of the header in 16 byte (paragraphs).  This is │
  527. │         │      │ used to locate the beginning of the load module in   │
  528. │         │      │ the file.  Although the DOS loader will allow the    │
  529. │         │      │ actual program to begin at any location specified by │
  530. │         │      │ this value some debuggers, including Microsoft's,    │
  531. │         │      │ need the program to be aligned on a 512-byte boundary│
  532. │         │      │ in the .EXE file.                                    │
  533. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  534. │ 0Ah-0Bh │ WORD │ Minimum number of 16 byte paragraphs required above  │
  535. │         │      │ the end of the loaded program.                       │
  536. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  537. │ 0Ch-0Dh │ WORD │ Max number of 16 byte paragraphs required above the  │
  538. │         │      │ end of the loaded program. If the minimum and maximum│
  539. │         │      │ number of paragraphs are both zero, the program will │
  540. │         │      │ be loaded as high in memory as possible.             │
  541. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  542. │ 0Eh-0Fh │ WORD │ Displacement in paragraphs of stack segment within   │
  543. │         │      │ load module.  This size must be adjusted by          │
  544. │         │      │ relocation.                                          │
  545. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  546. │ 10h-11h │ WORD │Offset to be in SP register when the module is given  │
  547. │         │      │ control  (stack offset)                              │
  548. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  549. │ 12h-13h │ WORD │ Checksum - 16-bit negative sum of all the words in   │
  550. │         │      │ the file, ignoring overflow.                         │
  551. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  552. │ 14h-15h │ WORD │ Offset for the IP register when the module is given  │
  553. │         │      │ control  (initial instruction pointer)               │
  554. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  555. │ 16h-17h │ WORD │ Offset in paragraphs of code segment (CS) within load│
  556. │         │      │ module.  This size must be adjusted by relocation.   │
  557. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  558. │ 18h-19h │ WORD │ Offset in bytes of the relocation pointer table.     │
  559. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  560. │ 1Ah-1Bh │ WORD │ Overlay number (0 for the resident part of the       │
  561. │         │      │ program)                                             │
  562. ├─────────┼──────┼──────────────────────────────────────────────────────┤
  563. │   1Ch   │ BYTE │ (undocumented) Microsoft compilers put 01h here,     │
  564. │         │      │ which may indicate the version of .EXE header        │
  565. │         │      │ structure for later changes.  Normally the relocation│
  566. │         │      │ table begins at 1Eh, but that can be changed to a    │
  567. │         │      │ different location if the word at 18-19h is adjusted │
  568. │         │      │ to match.                                            │
  569. └─────────┴──────┴──────────────────────────────────────────────────────┘
  570.  
  571.  
  572.  
  573. The Relocation Table ............................................ 7**13
  574.  
  575.   The word at 18h locates the first entry in the relocation table.  
  576. The relocation table is made up of a variable number of relocation 
  577. items.  The number of items is contained at offset 06h.  The 
  578. relocation item contains two fields - a 2 byte offset value, followed 
  579. by a 2 byte segment value.  These two fields represent the 
  580. displacement into the load module before the module is given control.  
  581. The process is called relocation and is accomplished as follows: 
  582.  
  583. 1. The formatted part of the header is read into memory.  Its size
  584.    is 1Bh.
  585.  
  586. 2. A portion of memory is allocated depending on the size of the load 
  587.    module and the allocation numbers in offsets 0Ah and 0Ch. DOS 
  588.    always tries to allocate 0FFFFh paragraphs. Since this call will 
  589.    always fail, the function returns the amount of free memory. If 
  590.    this block is larger than the minimum specified at offset 0Ah and 
  591.    the loaded program size, DOS will allocate the size specified at 
  592.    offset 0Ch or the largest free memory space, whichever is less. 
  593.  
  594. 3. A Program Segment Prefix is built following the resident portion of 
  595.    the program that is performing the load operation. 
  596.  
  597. 4. The formatted part of the header is read into memory (its size is 
  598.    at offset 08h) 
  599.  
  600. 5. The load module size is determined by subtracting the header size 
  601.    from the file size. Offsets 04h and 08h can be used for this 
  602.    calculation. The actual size is downward adjusted based on the 
  603.    contents of offset 02h. Note that all files created by the Linker 
  604.    programs prior to version 1.10 always placed a value of 4 at this 
  605.    location, regardless of the actual program size. Therefore, 
  606.    Microsoft recommends that this field be ignored if it contains a 
  607.    value of 4. Based on the setting of the high/low loader switch, an 
  608.    appropriate segment is determined for loading the load module. This 
  609.    segment is called the start segment. 
  610.  
  611. 6. The load module is read into memory beginning at the start segment. 
  612.    The relocation table is an ordered list of relocation items. The 
  613.    first relocation item is the one that has the lowest offset in the 
  614.    file. 
  615.  
  616. 7. The relocation table items are read into a work area one or more at 
  617.    a time. 
  618.  
  619. 8. Each relocation table item segment value is added to the start 
  620.    segment value. The calculated segment, in conjunction with the 
  621.    relocation item offset value, points to a word in the load module 
  622.    to which is added the start segment value. The result is placed 
  623.    back into the word in the load module. 
  624.  
  625. 9. Once all the relocation items have been processed, the SS and SP 
  626.    registers are set from the values in the header and the start 
  627.    segment value is added to SS. The ES and DS registers are set to 
  628.    the segment address of the program segment prefix. The start 
  629.    segment value is added to the header CS register value. The result, 
  630.    along with the header IP value, is used to give the module control. 
  631.  
  632.  
  633.  
  634. "NEW" .EXE Format (Microsoft Windows and OS/2) .................. 7**14
  635.  
  636.   The "old" EXE format is documented here.  The "new" EXE format puts 
  637. more information into the header section and is currently used in 
  638. applications that run under Microsoft Windows.  The linker that 
  639. creates these files comes with the Microsoft Windows Software 
  640. Development Kit and is called LINK4.  If you try to run a Windows-
  641. linked program under DOS, you will get the error message "This program 
  642. requires Microsoft Windows".  The OS/2 1.x file format is essentially 
  643. the same as the Windows format. 
  644.  
  645.   Windows executables have dynamic linking and all of the code/data 
  646. inside an EXE file is not necessarily loaded at run time. 
  647.  
  648.   Offset 3Ch dword: offset of new .EXE header (for Microsoft Windows & 
  649. OS/2) 
  650.  
  651.  
  652.  
  653. Standard File Control Block ..................................... 7**15
  654.  
  655.   The standard file control block is defined as follows, with offsets 
  656. in hex: 
  657.  
  658. ┌───────────────────────────────────────────────────────────────────────┐
  659. │              F I L E      C O N T R O L      B L O C K                │
  660. ├───────┬─────────┬─────────────────────────────────────────────────────┤
  661. │offset │  size   │                      Function                       │
  662. ├───────┼─────────┼─────────────────────────────────────────────────────┤
  663. │   0   │ 1 byte  │ Drive number. For example:                          │
  664. │       ├─────────┴─────────────────────────────────────────────────────┤
  665. │       │ Before open:    00h = default drive                           │
  666. │       │                 01h = drive A:                                │
  667. │       │                 02h = drive B: etc.                           │
  668. │       │ After open:     00h = drive C:                                │
  669. │       │                 01h = drive A:                                │
  670. │       │                 02h = drive B: etc.                           │
  671. │       │ A zero is replaced by the actual drive number during opening. │
  672. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  673. │  1-8  │ 8 bytes │ Filename, left justified with blanks.               │
  674. │       ├─────────┴─────────────────────────────────────────────────────┤
  675. │       │ If a reserved device name is placed here (such as PRN) do not │
  676. │       │ include the optional colon.                                   │
  677. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  678. │  9-B  │ 3 bytes │ Filename extension, left justified with trailing    │
  679. │       │         │ blanks.                                             │
  680. ├───────┼─────────┼─────────────────────────────────────────────────────┤
  681. │  C-D  │ 2 bytes │ Current block # relative to start of file, starting │
  682. │       │         │ with 0                                              │
  683. │       ├─────────┴─────────────────────────────────────────────────────┤
  684. │       │ (set to 0 by the OPEN function call).  A block consists of    │
  685. │       │ 128 records, each of the size specified in the logical record │
  686. │       │ size field.  The current block number is used with the current│
  687. │       │ record field (below) for sequential reads and writes.         │
  688. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  689. │  E-F  │ 2 bytes │ Logical record size in bytes.                       │
  690. │       ├─────────┴─────────────────────────────────────────────────────┤
  691. │       │ Set to 80h by OPEN function.  If this is not correct, you     │
  692. │       │ must set the value because DOS uses it to determine the       │
  693. │       │ proper locations in the file for all disk reads and writes.   │
  694. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  695. │ 10-13 │ 4 bytes │ File size in bytes.                                 │
  696. │       ├─────────┴─────────────────────────────────────────────────────┤
  697. │       │ In this field, the first word is the low-order part of the    │
  698. │       │ size.                                                         │
  699. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  700. │ 14-15 │ 2 bytes │Date file was created or last updated.               │
  701. │       ├─────────┴─────────────────────────────────────────────────────┤
  702. │       │ MM/DD/YY are mapped as follows:                               │
  703. │       │         15  14  13  12  11  10  9  8  7  6  5  4  3  2  1  0  │
  704. │       │         y   y   y   y   y   y   y  m  m  m  m  d  d  d  d  d  │
  705. │       │ where:            mm is 1-12                                  │
  706. │       │                   dd is 1-31                                  │
  707. │       │                   yy is 0-119 (1980-2099)                     │
  708. ├───────┼────────┬──────────────────────────────────────────────────────┤
  709. │ 16-17 │ 2 bytes│ Time file was created or last updated.               │
  710. ├───────┼────────┴──────────────────────────────────────────────────────┤
  711. │       │ These bytes contain the time when the file was created or     │
  712. │       │ last updated.  The time is mapped in the bits as follows:     │
  713. │       ├───────────────────────────────┬───────────────────────────────┤
  714. │       │         B Y T E   16h         │         B Y T E   17h         │
  715. │       ├───────────────────────────────┼───────────────────────────────┤
  716. │       │ F   E   D   C   B   A   9   8 │ 7   6   5   4   3   2   1   0 │
  717. │       ├───────────────────┬───────────┴───────────┬───────────────────┤
  718. │       │ H   H   H   H   H │ M   M   M   M   M   M │ D   D   D   D   D │
  719. │       ├───────────────────┼───────────────────────┼───────────────────┤
  720. │       │ binary # hrs 0-23 │ binary # minutes 0-59 │ bin. # 2-sec incr │
  721. │       ├───────────────────┴───────────────────────┴───────────────────┤
  722. │       │ note: The time is stored with the least significant byte first│
  723. ├───────┼────────┬──────────────────────────────────────────────────────┤
  724. │ 18-19 │ 2 bytes│ Reserved for DOS.                                    │
  725. ├───────┼────────┼──────────────────────────────────────────────────────┤
  726. │  20   │ 1 byte │ Current relative record number.                      │
  727. │       ├────────┴──────────────────────────────────────────────────────┤
  728. │       │ (0-127) within the current block.  This field and the Current │
  729. │       │ Block field at offset 0Ch make up the record pointer.  This   │
  730. │       │ field is not initialized by the OPEN (0Fh) function call.     │
  731. │       │ You must set this field before doing sequential read-write    │
  732. │       │ operations to the diskette.  To read the first record of a    │
  733. │       │ file, set this value to zero.                                 │
  734. ├───────┼─────────┬─────────────────────────────────────────────────────┤
  735. │ 21-25 │ 4 bytes │ Relative Record.                                    │
  736. │       ├─────────┴─────────────────────────────────────────────────────┤
  737. │       │ Points to the currently selected record, counting from the    │
  738. │       │ beginning of the file starting with 0.  This field is not     │
  739. │       │ initialized by the OPEN system call.  You must set this field │
  740. │       │ before doing a random read or write to the file.              │
  741. │       │  If the record size is less than 64 bytes, both words are     │
  742. │       │ used.  Otherwise, only the first 3 bytes are used.  Note that │
  743. │       │ if you use the File Control Block at 5Ch in the program       │
  744. │       │ segment, the last byte of the FCB overlaps the first byte of  │
  745. │       │ the unformatted parameter area.                               │
  746. └───────┴───────────────────────────────────────────────────────────────┘
  747.         
  748. note 1) An unopened FCB consists of the FCB prefix (if used), drive 
  749.         number, and filename.ext properly filled in. An open FCB is 
  750.         one in which the remaining fields have been filled in by the 
  751.         CREAT or OPEN function calls. 
  752.      2) Bytes 0-5 and 32-36 must be set by the user program. Bytes 16-
  753.         31 are set by DOS and must not be changed by user programs. 
  754.      3) All word fields are stored with the least significant byte 
  755.         first. For example, a record length of 128 is stored as 80h at 
  756.         offset 14, and 00h at offset 15. 
  757.  
  758.   Oddly, when Microsoft added the handle calls to DOS they still left 
  759. the old FCB calls with a few advantages.  Handle calls still can't 
  760. read volume labels or directory files and don't support wild card 
  761. deletions.  Microsoft has always claimed that they would eventually 
  762. fix these weaknesses, but we're up to DOS 6.0 and it isn't soup yet. 
  763.  
  764.   Microsoft has always hinted that they would eventually drop FCB 
  765. support from DOS.  Since many compiler runtime libraries depend on FCB 
  766. calls since they are the only ones portable across all DOS versions, a 
  767. lot of existing (expensive) commercial software would no longer run.  
  768. Also note that even the OS/2 Compatibility Box supports FCB calls. 
  769.  
  770.   Many of the handle calls are simply "front ends" for the existing 
  771. FCB code anyway.  It's unlikely the FCB calls will ever vanish from 
  772. DOS. 
  773.  
  774.  
  775. Extended File Control Block ..................................... 7**16
  776.  
  777.   The extended file control block is used to create or search for 
  778. files in the disk directory that have special attributes. 
  779.  
  780.   It adds a 7 byte prefix to the FCB, formatted as follows:
  781.  
  782. ┌────────────────────────────────────────────────────────────────────────┐
  783. │    E X T E N D E D     F I L E      C O N T R O L      B L O C K       │
  784. ├───────┬─────────┬──────────────────────────────────────────────────────┤
  785. │Offset │   Size  │                      Function                        │
  786. ├───────┼─────────┼──────────────────────────────────────────────────────┤
  787. │  00h  │ 1 byte  │ Flag byte containing 0FFh to indicate an extended FCB│
  788. ├───────┼─────────┼──────────────────────────────────────────────────────┤
  789. │  01h  │ 4 bytes │ Reserved by Microsoft                                │
  790. ├───────┼─────────┼──────────────────────────────────────────────────────┤
  791. │  06h  │ 2 bytes │ Attribute byte                                       │
  792. │       ├─────┬───┼──────────────────────────────────────────────────────┤
  793. │       │ hex │bit│                       meaning                        │
  794. │       ├─────┼───┼──────────────────────────────────────────────────────┤
  795. │       │ 00h │   │ (no bits set) normal; can be read or written without │
  796. │       │     │   │ restriction                                          │
  797. │       │ 01h │ 0 │ file is marked read-only.  An attempt to open the    │
  798. │       │     │   │ file for output using int 21h/fn 3Dh will fail and   │
  799. │       │     │   │ an error code will be returned.  This value can be   │
  800. │       │     │   │ used with other values below.                        │
  801. │       │ 02h │ 1 │ indicates a hidden file.  The file is excluded from  │
  802. │       │     │   │ normal directory searches.                           │
  803. │       │ 04h │ 2 │ indicates a system file.  The file is excluded from  │
  804. │       │     │   │ normal directory searches.                           │
  805. │       │ 08h │ 3 │ indicates that the entry contains the volume label   │
  806. │       │     │   │ in the first 11 bytes.  The entry has no other       │
  807. │       │     │   │ usable information and may exist only in the root    │
  808. │       │     │   │ directory.                                           │
  809. │       │ 10h │ 4 │ indicates that the file is a subdirectory            │
  810. │       │ 20h │ 5 │ indicates an archive bit.  This bit is set to on     │
  811. │       │     │   │ whenever the file is written to and closed.  Used by │
  812. │       │     │   │ BACKUP and RESTORE.                                  │
  813. │       │     │ 6 │ reserved, set to 0                                   │
  814. │       │     │ 7 │ reserved, set to 0                                   │
  815. │       ├─────┴───┴──────────────────────────────────────────────────────┤
  816. │       │ note 1) Bits 6 and 7 may be used in OS/2.                      │
  817. │       │ note 2) Attributes 08h and 10h cannot be changed using         │
  818. │       │         int21/43h.    │                                        │
  819. │       │ note 3) The system files IBMBIO.COM and IBMDOS.COM (or         │
  820. │       │         customized equivalent) are marked as read-only, hidden,│
  821. │       │         and system  files.  Files can be marked hidden when    │
  822. │       │         they are created.                                      │
  823. │       │ note 4) Read-only, hidden, system and archive attributes may   │
  824. │       │         be changed with int21h/fn43h.                          │
  825. │       │                                                                │
  826. │       │ Refer to int 21h/fn11h (Search First) for details on using the │
  827. │       │ attribute bits during directory searches.  This function is    │
  828. │       │ present to allow applications to define their own files as     │
  829. │       │ hidden (and thereby excluded from normal directory searches)   │
  830. │       │ and to allow selective directory searches                      │
  831. └───────┴────────────────────────────────────────────────────────────────┘
  832.  
  833.   Any reference in the DOS function calls to an FCB, whether opened or 
  834. unopened, may use either a normal or extended FCB.  If you are using 
  835. an extended FCB, the appropriate register should be set to the first 
  836. byte of the prefix, rather than the drive-number field. 
  837.  
  838.   Common practice is to refer to the extended FCB as a negative offset 
  839. from the first byte of a standard File Control Block. 
  840.  
  841.  
  842. Disk Transfer Area .............................................. 7**17
  843.  
  844.   The old-style (DOS 1.x compatible) FCB-oriented function calls use a 
  845. buffer called the Disk Transfer Area (DTA) for disk access.  Use of 
  846. the DTA is documented in Chapter 6, "DOS Memory Control Blocks and 
  847. Work Areas." 
  848.  
  849.  
  850.